<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "tigris-branding/css/tigris.css";
  @import "tigris-branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="tigris-branding/css/print.css"/>
<script type="text/javascript" src="tigris-branding/scripts/tigris.js"></script>
<title>cvs2svn Features</title>
</head>

<body id="bodycol">
<div class="app">

<h1>cvs2svn Features</h1>

<p>The primary goal of cvs2svn is to migrate as much information as
possible from your old CVS repository to your new Subversion or git
repository.</p>

<p>Unfortunately, CVS doesn't record complete information about your
project's history.  For example, CVS doesn't record what file
modifications took place together in the same CVS commit.  Therefore,
cvs2svn attempts to infer from CVS's incomplete information what
<em>really</em> happened in the history of your repository.  So the
second goal of cvs2svn is to reconstruct as much of your CVS
repository's history as possible.</p>

<p>The third goal of cvs2svn is to allow you to customize the
conversion process and the form of your output repository as flexibly
as possible.  cvs2svn has very many conversion options that can be
used from the command line, many more that can be configured via an
options file, and provides many hooks to allow even more extreme
customization by writing Python code.</p>

<h2><a name="list">Feature summary</a></h2>

<dl>

  <dt>No information lost</dt>
  <dd>cvs2svn works hard to avoid losing any information from your CVS
    repository (unless you specifically ask for a partial conversion
    using <tt>--trunk-only</tt> or <tt>--exclude</tt>).</dd>

  <dt>Changesets</dt>
  <dd>CVS records modifications file-by-file, and does not keep track
    of what files were modified at the same time.  cvs2svn uses
    information like the file modification times, log messages, and
    dependency information to deduce the original changesets.  cvs2svn
    allows changesets that affect multiple branches and/or multiple
    projects (as is allowed by CVS), or it can be configured to split
    such changesets up into separate commits
    (<tt>--no-cross-branch-commits</tt>; see also options file).</dd>

  <dt>Multiproject conversions</dt>
  <dd>cvs2svn can convert a CVS repository that contains multiple
    projects into a single Subversion repository with the conventional
    multiproject directory layout.  See <a
    href="faq.html#onetoone">the FAQ</a> for more information.</dd>

  <dt>Branch vs. tag</dt>
  <dd>CVS allows the same symbol name to be used sometimes as a
    branch, sometimes as a tag.  cvs2svn has options and heuristics to
    decide how to convert such "mixed" symbols
    (<tt>--symbol-hints</tt>, <tt>--force-branch</tt>,
    <tt>--force-tag</tt>, <tt>--symbol-default</tt>).</dd>

  <dt>Branch/tag exclusion</dt>
  <dd>cvs2svn allows the user to specify branches and/or tags that
    should be excluded from the conversion altogether
    (<tt>--symbol-hints</tt>, <tt>--exclude</tt>).  It checks that the
    exclusions are self-consistent (e.g., it doesn't allow a branch to
    be excluded if a branch that sprouts from it is not excluded).</dd>

  <dt>Branch/tag renaming</dt>
  <dd>cvs2svn can rename branches and tags during the conversion using
    regular-expression patterns (<tt>--symbol-transform</tt>).</dd>

  <dt>Choosing SVN paths for branches/tags</dt>
  <dd>You can choose what SVN paths to use as the trunk/branches/tags
    directories (<tt>--trunk</tt>, <tt>--branches</tt>,
    <tt>--tags</tt>), or set arbitrary paths for specific CVS
    branches/tags (<tt>--symbol-hints</tt>).  For example, you might
    want to store some tags to the <tt>project/tags</tt> directory,
    but others to <tt>project/releases</tt>.</dd>

  <dt>Branch and tag parents</dt>
  <dd>In many cases, the CVS history is ambiguous about which branch
    served as the parent of another branch or tag.  cvs2svn determines
    the most plausible parent for symbols using cross-file
    information.  You can override cvs2svn's choices on a case-by-case
    basis by using the <tt>--symbol-hints</tt> option.</dd>

  <dt>Branch and tag creation times</dt>
  <dd>CVS does not record when branches and tags are created.  cvs2svn
    creates branches and tags at a reasonable time, consistent with
    the file revisions that were tagged, and tries to create each one
    within a single Subversion commit if possible.</dd>

  <dt>Mime types</dt>
  <dd>CVS does not record files' mime types.  cvs2svn provides several
    mechanisms for choosing reasonable file mime types
    (<tt>--mime-types</tt>, <tt>--auto-props</tt>).</dd>

  <dt>Binary vs. text</dt>
  <dd>Many CVS users do not systematically record which files are
    binary and which are text.  (This is mostly important if the
    repository is used on non-Unix systems.)  cvs2svn provides a
    number of ways to infer this information
    (<tt>--eol-from-mime-type</tt>, <tt>--default-eol</tt>,
    <tt>--keywords-off</tt>, <tt>--auto-props</tt>).</dd>

  <dt>Subversion file properties</dt>
  <dd>Subversion allows arbitrary text properties to be attached to
    files.  cvs2svn provides a mechanism to set such properties when a
    file is first added to the repository
    (<tt>--auto-props</tt>) as well as a hook that users can use to
    set arbitrary file properties via Python code.</dd>

  <dt>Handling of <tt>.cvsignore</tt></dt>
  <dd><tt>.cvsignore</tt> files in the CVS repository are converted
    into the equivalent <tt>svn:ignore</tt> properties in the output.
    By default, the <tt>.cvsignore</tt> files themselves are
    <em>not</em> included in the output; this behavior can be changed
    by specifying the <tt>--keep-cvsignore</tt> option.</dd>

  <dt>Subversion repository customization</dt>
  <dd>cvs2svn provides many options that allow you to customize the
    structure of the resulting Subversion repository
    (<tt>--trunk</tt>, <tt>--branches</tt>, <tt>--tags</tt>,
    <tt>--include-empty-directories</tt>, <tt>--no-prune</tt>,
    <tt>--symbol-transform</tt>, etc.; see also the additional
    customization options available by using the <a
    href="#options-file-method"><tt>--options</tt>-file
    method</a>).</dd>

  <dt>Support for multiple character encodings</dt>
  <dd>CVS does not record which character encoding was used to store
    metainformation like file names, author names and log messages.
    cvs2svn provides options to help convert such text into UTF-8
    (<tt>--encoding</tt>, <tt>--fallback-encoding</tt>).</dd>

  <dt>Vendor branches</dt>
  <dd>CVS supports "vendor branches", which (under some circumstances)
    affect the contents of the main line of development.  cvs2svn
    detects vendor branches whenever possible and handles them
    intelligently.  For example,
    <ul>

      <li>cvs2svn explicitly copies vendor branch revisions back to
        trunk so that a checkout of trunk gives the same results under
        SVN as under CVS.</li>

      <li>If a vendor branch is excluded from the conversion, cvs2svn
        grafts the relevant vendor branch revisions onto trunk so that
        the contents of trunk are still the same as in CVS.  If other
        tags or branches sprout from these revisions, they are grafted
        to trunk as well.</li>

      <li>When a file is imported into CVS, CVS creates two revisions
        ("1.1" and "1.1.1.1") with the same contents.  cvs2svn
        discards the redundant "1.1" revision in such cases (since
        revision "1.1.1.1" will be copied to trunk anyway).</li>

      <li>Often users create vendor branches unnecessarily by using
        "cvs import" to import their own sources into the CVS
        repository.  Such vendor branches do not contain any useful
        information, so by default cvs2svn excludes any vendor branch
        that was only used for a single import.  You can change this
        default behavior by specifying the
        <tt>--keep-trivial-imports</tt> option.</li>

    </ul>

  </dd>

  <dt>CVS quirks</dt>
  <dd>cvs2svn goes to great length to deal with CVS's many quirks.
    For example,
    <ul>

      <li>CVS introduces spurious "1.1" revisions when a file is added
        on a branch.  cvs2svn discards these revisions.</li>

      <li>If a file is added on a branch, CVS introduces a spurious
        "dead" revision at the beginning of the branch to indicate
        that the file did not exist when the branch was created.
        cvs2svn deletes these spurious revisions and adds the file on
        the branch at the correct time.</li>

    </ul>
  </dd>

  <dt>Robust against repository corruption</dt>
  <dd>cvs2svn knows how to handle several types of CVS repository
    corruption that have been reported frequently, and gives
    informative error messages in other cases:
    <ul>

      <li>An RCS file that exists both in and out of the "Attic"
        directory.</li>

      <li>Multiple deltatext blocks for a single CVS file
        revision.</li>

      <li>Multiple revision headers for the same CVS file
        revision.</li>

      <li>Tags and branches that refer to non-existent revisions or
        ill-formed revision numbers.</li>

      <li>Repeated definitions of a symbol name to the same revision
        number.</li>

      <li>Branches that have no associated labels.</li>

      <li>A directory name that conflicts with a file name (in or out
        of the Attic).</li>

      <li>Filenames that contain forbidden characters.</li>

      <li>Log messages with variant end-of-line styles.</li>

      <li>Vendor branch declarations that refer to non-existent
        branches.</li>

    </ul>
  </dd>

  <dt>Timestamp error correction</dt>
  <dd>Many CVS repositories contain timestamp errors due to servers'
    clocks being set incorrectly during part of the repository's
    history.  cvs2svn's history reconstruction is relatively robust
    against timestamp errors and it writes monotonic timestamps to the
    Subversion repository.</dd>

  <dt>Scalable</dt>
  <dd>cvs2svn stores most intermediate data to on-disk databases so
    that it can convert very large CVS repositories using a reasonable
    amount of RAM.  Conversions are organized as multiple passes and
    can be restarted at an arbitrary pass in the case of
    problems.</dd>

  <dt>Configurable/extensible using Python</dt>
  <dd>Many aspects of the conversion can be customized using Python
    plugins that interact with cvs2svn through documented interfaces
    (<tt>--options</tt>).</dd>

</dl>

</div>
</body>
</html>
